[レポート]レガシーシステム、モダナイズへの道筋 #AWSDevDay

モダナイズとはなんなのか。どうすれば良いのか。越えなければいけない壁とは？実際にどんな乗り越え方のパターンがあるのか。そんなことをふんだんに盛り込んでくれたセッションでした！頷きすぎて首がもげるかと思いました。

#セッションレポート

今泉大樹

2023.06.24

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは。AWS事業本部コンサルティング部に所属している今泉（@bun76235104）です。

私はAWSの DEV DAY 2023 TOKYOに参加させていただきました

その中で DAY 2 の「レガシーシステム、モダナイズへの道筋」というセッションを試聴したため、概要や私なりの感想を記事として投稿したいと思います！

【2023/6/26 追記】

スピーカーの門別により、登壇資料などが公開されていますので、ぜひご確認ください！

スピーカーについて

クラスメソッド株式会社
AWS事業本部コンサルティング部 ソリューションアーキテクト
門別 優多 氏

AWS事業本部コンサルティング部にAWSエンジニアとして入社。
その後開発部門へ異動し、モダンアプリケーション開発に携わる。
再びコンサルティング部へ戻り、新たなモダンアプリコンサルサービスの提供を開始する。
AWSを活用したアプリケーションの開発、並びにモダンアプリケーションコンサルティングが得意。

弊社の門別がスピーカーであり、私もまっさらな状態で楽しまさせてもらいました。

セッションの構成

【2023/6/26 追記】

再掲となりますが、スピーカーの門別により、登壇資料などが公開されていますので、ぜひご確認ください！

目次は以下のとおりでした。

なぜモダナイズをしたい？
モダナイズ種類
マイクロサービスするべき？
システムとデータベースの共存・分離
本番環境へのリリース
レガシーシステムモダナイズへの道筋

以下はそれぞれの章について、内容の簡単なまとめと私の感想を記載いたします。

なぜモダナイズしたいのか

レガシーシステムのよくある課題をあげながら、モダナイズへ向けたモチベーションや目指したい利用の姿について話をしていました。

例えばレガシーシステムの課題としては以下のようなものが挙げられていました。

EOLを迎えている、運用コストが高い
サービスそのものが使いにくい
中のソースコードを見ると設計・実装がつらかった

これらのような原因で開発者体験を損ねたり、結果的に良いものが作れなかったり、微妙だと思っているシステムを改修できなかったりとなりかねないとのこと。

このような状態になると、「負のスパイラルを抜け、改善のサイクルへ向かう」ことが重要になり、レガシーシステムの刷新や、内製化、モダナイズといったものが必要になってくるとのことでした。

モダナイズの種類

モダナイズにも以下のような種類があるとのことでした。

既存システムのリファクタリング
Big Bang Rewrite, Relase
- 既存システムを一から作り直す
- システムのリプレースでは選択されがち
- リリースのリスクは高い
Strangler Fig pattern
- 既存システムの機能ごとに徐々にリライトしていくパターン
- 部分的に新システムに切り替えるためリスクを最小限にできる

スピーカーとしては Strangler Fig pattern がおすすめとのこと。

AWSでやる一例としては、旧システムとは別に新システムを稼働（例えばECS Faragateなどで）し、特定の機能を呼び出す処理について、新システムにトラフィックを流すようなことです。

例えばALBなどで特定のパスに対しては新システムの方に流すような形です。(/v2/blogs というパスに関しては新システムにトラフィックを流し、それ以外は旧システムに流すような。)

マイクロサービス化するべきか

最初にスピーカー的結論を述べていました。

「ステップアップで導入がおすすめ」

というのも、マイクロサービスには多くのメリットがあるものの、サービス間通信・トランザクションの管理・SAGAパターンなど考えることが多いとのこと。

スピーカーとしては「まずはレガシーシステムから身動きが取れる状態にすること」が大事であると話をされていました。

スピーカーは「小さく成功体験を積んでチームのレベルを上げる」ということを繰り返し話をしていたので、いきなり全てマイクロサービスに移行！とするよりも、小さく変更や機能改修をできる状態にしていくことが先決ということをお話ししていたのかと思います。

また、既存システムが動作している限り既存のDBから新規DBへの移行は避けては通れないため、考える必要があるとのこと。

具体的には以下のようなパターンを紹介されていました。

新システムへのDB移行パターン1（既存DBを参照する新システムのパターン）

主に以下のようなステップを踏むパターンです。

既存DBを参照する新システムを作成
移行が完了後、新システムだけにする
- 新システムだけの稼働にするときに、大規模な改修とかが必要になる可能性が高い
- 可能ならば少しづつリライト・リリースする
新システムでDB設計の見直しをする

一見良さそうに見えるのですが、移行が完了後、新システムだけにするの際に、大規模な変更・大規模なリリースになりがちというデメリットがあるとのこと。

新システムへのDB移行パターン2（既存のレガシーシステムにAPIを作る場合）

技術的負債を解決する前に、機能を実装する必要がある場合もあるとのこと。

そのような場合には以下のパターンが考えられるとのこと。

既存システムにAPIを追加
既存システムのAPIをよぶ新システムを作成
既存システムのAPIをサービスとして分離
データベースを分離する

新システムへのDB移行パターン3（データベースとサービスを分離する場合）

機能のデータベース切り出し
新システムからも読み書き
新システムから新サービスに書き込み・参照
どんどん既存システムから機能を切り出す
既存システムをもぬけの殻にする
新システムに完全移行する

ここでもスピーカーは「既存システムから段階的に移行していくことがポイント」と話していました。

いずれのパターンにしろ、大きな変更を一発で切り替え！ということではなく、小さな単位で変更や切り替えをしていくことがおすすめ。ということを言いたかったのかと感じました。

本番環境へのリリース

スムーズなモダナイズとは？

スピーカー的な結論としては「開発体験をあげて小さいリリースをたくさんして成功体験を積もう」とのこと。

開発体験をあげるとは？以下のような例があるとのこと。

手で動作確認をせずにテストを書く（テストは絶対に書く）
- 状態を持たないテストから書いていく
- 最低限ビジネスにコアに関わる領域など
- テストを書かないとモダナイズの意味がない
- 手動テストを全部やめるという意味ではない
- 動作確認としてテストがある状態
小さくリリースする
- Feature Flagを活用、新機能や改修をリリースする
- 切り戻しができる小さな粒度でリリースをしていく
成功体験を積む
- チームのレベルを上げるのに必要不可欠
- 成功体験を踏むことで、新しい技術スタックに挑戦する余裕が出てくる
- 失敗は次に活かす！